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PREFACE 


This publication is designed to present concepts of Telepro- 

cessing to persons familiar with computer applications in € 
the business and scientific fields, but who have not yet used 

the “long distance” computing techniques and equipment. 

The history of Teleprocessing introduces terminology and 

developments such as real-time, multiprogramming, and 

time-sharing. Present difficulties and possibilities for the 

future are included. 


Teleprocessing requires distinctive communication net- 
works, codes, and procedures for error detection and for 
control of terminals and message transmission. The devel- 
opment of specialized programming techniques that can 
handle the new complex applications is discussed in the sec- “, 
tion on applications and in the final section, which deals 
with the two access methods available: BTAM (Basic Tele- 
communications Access Method), and QTAM (Queued 
Telecommunications Access Method). A bibliography and 
glossary conclude the publication. 


Second Edition (July 1968) 
Significant changes or additions to the contents of this publication will be reported in 
subsequent revisions or technical newsletters. 
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This publication is an introduction to Teleprocessing con- 
cepts, system applications, equipment characteristics, and 
programming techniques for persons already familiar with 
conventional computer applications, equipment, and pro- 
gramming methods. Its purpose is to introduce the overall 
capabilities of the programming support for utilizing the 
IBM System/360 in Teleprocessing applications. There are 
two levels of support: the Basic Telecommunications Access 
Method (BTAM) and the more comprehensive Queued Tele- 
communications Access Method (QTAM). This publication 
provides background information for the detailed technical 
material in the corresponding Systems Reference Library 
(SRL) manuals concerning these two types of support. 


HISTORICAL REVIEW 


Although a majority of Teleprocessing (TP) computer sys- 
tems have been developed relatively recently, the potential 
benefits of these systems were noted by early computer 
users. It is important to realize that present TP equipment 
and programming techniques are not innovations but evolu- 
tionary steps in the development of computing systems. 

This evolutionary development has produced significant 
factors in present-day TP systems. One such factor is that 
much telecommunications equipment was developed long 
before the modern digital computer. As a consequence, 
facilities that were designed for convenient or economical 
data communication are not always ideally suited to a com- 
puter system. Teleprocessing demands new techniques not 
required for input/output devices designed specifically as 
peripheral computer equipment. Another factor is that data 
is often entered into a computer directly from a terminal 
unit. This direct man-machine communication requires data 
validation and programming procedures not encountered in 
off-line systems. 


Finally, perhaps the most significant factor to computer 
personnel first encountering TP applications is the unfamil- 
iar technical terminology. This makes TP concepts appear 
difficult and discourages many people from learning more 
about them. People who have little patience with TP termi- 
nology should consider the situation of a communications 
expert first encountering such common computer jargon as 
compiler, loader, dump, bug, and data set! 


The attachment of communications equipment to digital 
computers involves much more than establishing appropriate 
electrical connections; it also involves a merging of the sep- 
arate technologies of communications and computing. Sub- 
stantial new capabilities, not previously possible, become 
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practical; however, to capitalize on this potential, one must 
have a general understanding of TP devices and terminology 


and of associated computer equipment and programming 
techniques. This publication is designed to present this 
additional information to persons already familiar with 
computer systems. 


Developments in Teleprocessing 


It comes as a surprise to many that the first use of TP equip- 
ment with a computer occurred before the advent of stored 
program systems. As early as 1940, scientific calculations 
were telegraphed several hundred miles to an electromechan- 
ical calculator, and within a minute results were returned to 
the distant users. Such pioneering demonstrations indicate 
that there was an early awareness of the convenience of 
using a powerful calculator from distant locations. It is also 
worth noting that these early experiments were considered 
to be more than just connecting communications terminals 
to calculating equipment, to the extent that a patent was 
issued on one such system. Another interesting observation 
is that experimenters recognized that a calculator was fast 
enough to service several remote terminals concurrently, 
and, although the terms were not used then, the concept of 
Sharing the central calculator was a precursor of recent 
advances in multiprogramming (running several interleaved 
programs concurrently) and time-sharing (distributing the 
resources of a computer system to a number of independent 
users). 


During the early part of the decade following World War II, 
military planners realized that new approaches were needed 
to provide an adequate air-defense system. They recognized 
that vast amounts of data would have to be collected and 
processed, and results returned immediately to command 
personnel. These command personnel could interrogate the 
system and plan effective defensive action. Here then was a 
need for transmitting data from remote sensing devices (for 
example, radar stations) to a central computer, processing 
the data rapidly enough to influence the environment being 
monitored (that is, in “real-time”), and using a man-machine 
system to combine the judgment and experience of com- 
mand personnel with the rapid, accurate processing of a 
computer. The equipment and techniques formulated for 
such systems as SAGE (Semi-Automatic Ground Environ- 
ment) had a substantial influence on the evolution of 
similar systems for commercial applications. 
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The first commercial applications of communications- 
oriented computer systems were in industries that had 
requirements for real-time control or for rapid access to 
large data files. Hence, by the late 1950s, computers were 
installed for controlling both industrial processes and crit- 
ical time-dependent business inventories. A number of 
airline reservation systems were developed. At first, these 
used special-purpose, fixed-program machines to maintain 
inventories of passenger-seat space available on future flights. 
Soon, however, general-purpose systems were programmed 
to provide more general reservation-accounting functions. 
The design of the largest of these, SABRE (for Semi- 
Automatic Business Research Environment), was stimulated, 
as the name implies, by the earlier military systems. 


These general-purpose systems required special terminal 
units, separate channels to attach the communications 
equipment, modified processors to protect against inadver- 
tent destruction of data, additional core storage and special 
drums to hold transactions awaiting processing, and large 
disk files to hold the reservation data. Not only was com- 
mercially available equipment extensively modified and 
augmented with special devices, but also complicated, 
special-purpose programs were developed to control and 
coordinate the equipment complex. Developers soon recog- 
nized that the programming of large Teleprocessing systems 
was vitally important to system performance and reliability. 
Designing and testing these complex programs proved to 
require extremely competent personnel, long development 
schedules, and extensive amounts of machine time for 
testing.- 


Reliability and efficiency became as important for pro- 
grams as for equipment. The cost of programming 
approached, and in some cases exceeded, the cost of the 
equipment itself. Recognition of these factors indicated 
that widespread, economical use of such systems in com- 
mercial applications would require the development of: 


e Computers incorporating TP features as standard equip- 
ment rather than as special attachments. 


e General-purpose, pretested programs to service the Tele- 
processing environment. 


A third phase (after the military and business applica- 
tions) in the evolution of Teleprocessing systems began in 
the early 1960s. Although the earliest application of com- 
puters was to scientific problems, the potential of TP sys- 
tems in this area went relatively unnoticed. Even though 
computer equipment had become more economical and, 
with the introduction of operating systems, more conven- 
ient and efficient, user access to scientific computers was 
not improved. In fact, individual users often were experi- 
encing more inconvenience and longer turnaround time (the 


interval between submitting a job and receiving results). 
The influence of turnaround time upon programmer pro- 
ductivity was most obvious where the results of computer 
processing were needed before other work could be per- 
formed. Several leading university computer centers, recog- 
nizing the impact of turnaround time on user productivity, 
developed the concept of providing many people with direct 
computer access via numerous remote terminal units sharing 
the central computer. Experienced people could apply their 
knowledge and judgment directly to the formulation and 
solution of complex scientific problems; inexperienced users 
could program and debug problems with less detailed com- 
puter knowledge. 


Teleprocessing Today 


The following trends summarize this historical introduction: 


e TP and computing technologies have different heritages 
with attendant differences in equipment requirements 
and technical terminology. 


e Present combinations of TP and computing technologies 
are the result of trends that have evolved over the past 
two decades. 


e Special-purpose equipment and computer features are 
being supplanted by general-purpose, communications- 
oriented computer equipment. 


e Special-purpose control programs are evolving into 
general-purpose, communications-oriented programming 
systems. 


At the present stage of development, the following factors 
are important: 


e Direct substitution of a TP system for a conventional 
computer system is no more sensible than rigid conver- 
sion of a manual accounting application to a computer. 
The best use of a new system is made not by doing an 
old job in the same manner on new equipment, but by 
rethinking the entire approach with consideration of new 
capabilities. 


e It is not currently feasible to satisfy all requirements with 
standard products and programming support. 


e@ However, many application requirements can be satisfied 
by standard, general-purpose computer equipment. 


e Also, a large number of applications can be processed 
under available operating systems augmented with 
communications-oriented control programs. 





System/360 


The IBM System/360 offers a complete set of integrated 
communications-oriented features: 


e A compatible family of central processing units with an 
interrupt facility and instruction repertoire designed spe- 
cifically to meet requirements of Teleprocessing; 


e A large, directly addressed, protected primary core stor- 
age for holding control and application programs and 
transaction queues; 


e Secondary storage devices with a wide spectrum of speed, 
capacity, and price characteristics; 


e Several types of transmission control units to attach 
communications lines to the computer; 


e A broad range of terminal devices for data collection, 
message input/output, and graphic display; 


e A range of facilities to control and coordinate the central 
processing equipment and the multiprogramming essen- 
tial for TP applications; 


e Two data-management access methods designed specif- 
ically for Teleprocessing. 


Access Methods 


The two access methods for IBM System/360 TP environ- 
ments are: 


1. Basic Telecommunications Access Method (BTAM), 
2. Queued Telecommunications Access Method (QTAM). 


Both of these access methods are available under either the 
full Operating System (OS ) or the smaller Disk Operating 





System (DOS). The two different versions.of programming 
support are necessary because of the considerable variation 
in TP system requirements. BTAM (Basic Telecommunica- 
tions Access Method) provides the programmer with simple, 
efficient access to the communications environment so that 
he can program terminal units in a manner consistent with 
that used for conventional sequential input/output devices. 
BTAM controls data transmission but it does not provide 
for elaborate message queuing or for processing of the mes- 
sage itself. 


The other access method, QTAM (Queued Telecommun- 
ications Access Method), provides all the capabilities just 
mentioned for BTAM. In addition, as the name implies, it 
includes facilities for queuing messages on direct-access 
storage devices. It also provides complete capabilities for 
data-collection and message-switching applications, among 
others. Like BTAM, QTAM insulates the programmer from 
most of the details of TP equipment. 


BTAM and QTAM alleviate many of the problems tradi- 
tionally associated with TP systems. In particular, they 
largely eliminate the need to train personnel in the details 
of TP equipment. With these tested packages, the program- 
mer need not be as concerned with the diabolically elusive 
bugs normally encountered in real-time system testing. The 
net result is more reliable programs developed sooner and at 
lower cost than is usually the case with specialized TP con- 
trol programs. BTAM and QTAM are not panaceas; they do 
not satisfy all application requirements. However, they do 
provide facilities for most applications, and, with modifica- 
tions, they can be extended to meet other needs. 


Readers desiring more detailed information on BTAM 
and QTAM may want to read the JBM System/360 Tele- 
communications Access Method section of this manual 
before studying the specific SRL manuals. Readers desiring 
general information on TP applications, equipment char- 
acteristics, and programming techniques should continue 
with the next section. 
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As already noted, the early use of TP systems in military 
command and control applications was necessary since there 
was no other realistic way to perform the job. In a commer- 
cial situation, whether with a business or a scientific orienta- 
tion, the evaluation of a TP system must include considera- 
tion of several factors besides mere technical feasibility. 
Justification of a TP system involves most of the same fac- 
tors that must be considered in installing a conventional 
computer system or converting a new application to an 
installed computer. Speed, accuracy, economy, and flexibil- 
ity must be evaluated as always; however, other factors 
become more significant: organizational disruption, system 
reliability, and personnel training, for example. It is diffi- 
cult to evaluate these factors, much less to assign quantita- 
tive measures to them. TP systems, however, are usually 
justified by such factors as: 


e Customer convenience. Brokerage firms, for example, 
require rapid execution and confirmation of customer 
orders. 


e Inventory control. Manufacturing applications are com- 
mon, but there are other “inventories” —such as airline 
space availability—that can be effectively controlled by a 
TP system. 


e Credit Control. Central data files can provide assurance 
that a customer has funds or credit approval. 


e Management control. Immediate access to centralized 
data files provides more timely information for control 
of business operations. 


e Industrial control. Computer control of key production 
factors increases productivity of capital equipment (for 
example, petroleum refineries). 


e Equipment centralization. In collecting data from remote 
sources, either intermittently (as in production data col- 
lection) or periodically (as in central summarizing of 
statistical data from distant branch offices), one central 
computer may do the processing that would otherwise 
require a separate system at each remote site. 


e Innovation. Some applications are just not possible with- 
out a TP system (for example, on-line debugging, text 
editing, and computer-assisted instruction). 


Teleprocessing System Applications 


A brief survey of some commonTP applications provides 
the background prerequisite to a description of the equip 
ment and programming characteristics of the TP environ- 
ment. The remainder of this section describes applications 
from the user’s viewpoint (that is, what the system does) 
rather than from the engineer’s or programmer’s viewpoint 
(that is, how the system operates). However, since the user 
must communicate with the system by means of a terminal 
device, commonly used terminal equipment is described and 
illustrated. 


DATA COLLECTION 


The most basic form of TP application, data entry, may 
involve several variations: 


1. Data can be transcribed first into some medium (for 
example, punched cards or paper tape) readable by the 
remote terminal. The medium is then placed in the terminal 
and, after contact is established with the central computer, 
the terminal reads the data and transmits it to the computer, 
which stores it for later processing. 


The IBM 1050 Data Communication System (see Fig- 
ure 1) is often used for this purpose. The 1050 can be 
employed for off-line data preparation as well as for on-line 
data transmission. It is a modular unit accommodating (as 
can be seen in the picture) data on both punched cards and 
paper tape. This form of data collection is similar to the 
data-conversion operations (for example, card-to-tape) per- 
formed at most computer installations. The principal differ- 
ence is that the reader is a terminal device located at a 
remote location rather than at the central computer site. 


2. Another approach is to key the data directly on-line 
to the computer, bypassing transcription to a physical med- 
ium. This approach precludes manual data verification and 
permits less efficient use of the communications line since 
data can be read from a terminal faster than it can be keyed 
manually. This manual keying can be described as “on-line 
keypunching.” 


3. In another variation of data collection, instead of the 
terminal site contacting the computer, the computer initiates 
the connection. With appropriate equipment, the computer 
can dial a terminal, read a batch of data, turn the terminal 
off, and “hang-up.” Computer-initiated dialing is known as 
autocalling, and terminal operation without an operator is 
known as unattended operation. This kind of data entry is 
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Figure 1. IBM 1050 Data Communication System 


often used to gather daily operating data from remote sites. 
The data is placed in the terminals at the close of the busi- 
ness day, and during the night the computer “‘calls” the 
terminals and collects the data. 


Often the same facilities that are used during the day for 
voice communication are used for data transmission after 
business hours, when they are free of voice traffic, or, in 
some instances, when lower tariffs (the rates charged by the 
communication companies) are in effect. 


4. Data may be sent to the computer intermittently 
rather than in batches. This requires a different form of 
communication with the computer since it would be imprac- 
tical to contact the computer every time data is ready. 
Instead, a group of terminals share a line that is always con- 
nected to the computer. This is termed a multipoint line 
since several terminals are connected to it simultaneously. 
This line is often “private,” meaning that it is privately 
owned or leased from a common carrier (a company provid- 
ing communications services). Since only one terminal can 
use the line at any one time, there are occasions when a ter- 
minal has to wait for the line to become free. Also, there 
must be some way to prevent several terminals from trying 
to use the line simultaneously. Two types of control are 
commonly used for multipoint lines: contention, in which 
the terminals contend for the line and an interlocking mech- 
anism resolves “‘tie’’ situations, and polling, in which a con- 
trol mechanism invites each terminal in turn to send any 
data that it has. 
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5. Two other varieties of data collection are often used 
in industrial applications. Sometimes a process is monitored 
by metering devices that automatically read out their cur- 
rent settings. Another form of production data collection 
uses an IBM 1030 Data Collection System (see Figure 2). 
Upon completion of a job, an employee enters into the 1030 
such data as his man number, the number of units produced, 
and the job status. This terminal is designed to operate in 
industrial environments and has special features for reading 
identification badges, coded data cartridges, and numerical 
counts. The computer records the time of completion, 
stores the record, and later processes it for labor accounting 
and production control purposes. The IBM 1030 is a good 
example of a job-oriented terminal performing functions 
unsuited to conventional data communications equipment. 


MESSAGE SWITCHING 


Data collection, as described above, involves neither on-line 
processing of message data nor transmission of data from 
the computer to a terminal. Message switching extends TP 
system capabilities to encompass these two additional 
functions. 


A message-switching configuration includes a number of 
terminals connected to a central computer. A message may 
be transmitted from a sending terminal to one or more 
receiving terminals by noting in the beginning portion of the. 











Figure 2. IBM 1030 Data Collection System 


message, called the message header, one or more symbolic 
addresses of the terminals to which the remaining part of 
the message, called the message text, is to be sent. The 
computer program analyzes the header, converts symbolic 
destinations to actual terminal locations, addresses the 
receiving terminal (that is, contacts it and determines if it 
can receive messages), and transmits the message. If an 
addressed terminal is busy sending or receiving other infor- 
mation or is otherwise unavailable, the computer program 
may store the message until the terminal is available, then 
send it. Because of this function, message switching is often 
called store and forward switching. 


Notice that, in addition to both sending and receiving 
data, the computer must also analyze the message header to 
identify the receiving terminals. These operations, as well 
as storing, or queuing (that is, placing in a waiting line), 
messages until the receiving terminals become available, are 
functions required for message switching but not needed in 
the data-collection applications described earlier. The pro- 


grammer must inform theTP program of the control charac- 
ters that delimit destination locations in the header and of 
means for determining the end of the header and beginning 
of the text. Tables relating symbolic locations to actual 
terminals must be established. In addition, the system must 
provide for checking for lost messages, retransmission in 
case of line errors, retrieval of earlier messages, addressing 
of groups of terminals, detection of invalid addresses, con- 
trol of the allocation of space for storing messages, recogni- 
tion of important messages and assignment of priority, and 
a number of similar operations. 





INQUIRY APPLICATIONS 


In this kind of application, an inquiry entered from a termi- 
nal is processed by the computer, data is retrieved from a 
file, and a reply is returned to the originating terminal. It 
differs from message switching in that the complete message 
text (in contrast to only the message header) is usually ana- 
lyzed, a central data file is referenced and maintained, and a 
new message is composed for return to the original (in con- 
trast to some other) terminal. 


This mode of terminal-computer communication is often 
termed conversational since sending and receiving operations 
alternate. The time interval between the completion of an 
inquiry and the beginning of a computer response is called 
the system response time, typically a period of a few sec- 
onds. The duration of conversations may vary considerably 
since a computer response may stimulate the terminal user 
to pose another inquiry. For example, if one particular air- 
line flight is fully booked, the customer may be interested 
in space available on flights at other times. 


Inquiry applications differ greatly according to the type 
of terminal employed as well as the type of central data file 
employed. A few examples will illustrate this point. 


Audio Response 


Certainly the most widely available terminal device imagin- 
able is the ordinary telephone. Although we all use it for 
communication with other people, it can also be employed 
for computer inquiry. A simple example is an inventory 
application by which a salesman wishes to determine the 
delivery period for an item. 


Even while in the customer’s office, the salesman can dial 
a central computer and then, using touch buttons, enter the 
item number of the product. Equipment at the computer 
site decodes the stock number, retrieves the associated inven- 
tory record from a central file, and determines the delivery 
time. Then the computer constructs a reply to the user and 
issues a series of codes to an audio-response device. This 
equipment obtains from its recorded vocabulary the appro- 
priate spoken words and sends them to the inquiring tele- 
phone. This audio response informs the salesman of the 
expected delivery time. The salesman can then discuss this 
with the customer and either enter the order (again via the 


telephone) or make another inquiry, perhaps for some 
related item. 


Figure 3 shows an IBM 7770 Audio Response Unit. A 
similar device, the IBM 7772, has a larger vocabulary, but 
cannot service as many communication lines as the 7770. 
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Figure 4. IBM 1060 Data Communication System 
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Figure 5. IBM 2260 Display Station 


Deposit Accounting 


Another common inquiry system is used in savings bank 
applications. A terminal specifically designed for this pur- 
pose, the IBM 1060 Data Communication System, is shown 
in Figure 4. Its keyboard is arranged for banking use; it 
can print directly upon a customer’s savings passbook. A 
typical operation involves keying in the passbook number 
together with the dollar amount to be deposited or with- 
drawn. This data is used by the computer to check a custo- 
mer record and update it with the new balance. Concur- 
rently, a message is returned to print the transaction, date, 
and new balance in the passbook. Many other functions, 
such as checking for overdrafts, stopping payment on lost 
books, and computing interest payments, are also provided. 


Information Retrieval 


In retrieving information from a large centralized data file, 
a user is often interested in examining an amount of data 
rather than in obtaining direct responses to specific inquiries. 
Consequently, there is a requirement for considerably faster 
output than in the other inquiry applications described. A 
visual display satisfies this requirement, and the IBM 2260 
Display Station (pictured in Figure 5) is often used in 
retrieval applications. The user enters a key word or a series 











Figure 6. IBM 2740 Communications Terminal 


of terms describing the area of interest. After analyzing 
these, the computer retrieves abstracts of related informa- 
tion and returns them to the display station. 


Displaying data on a 2260 screen is faster than printing 
the same data on a terminal printer. As a consequence, the 
user can scan a page and, by entering new keywords, either 
indicate a desire to receive another page or obtain more 
detailed information on topics currently displayed. In either 
case, this display is ideally suited to applications in which 
a considerable volume of information must be visually 
scanned. A new page of several hundred characters can be 
transmitted from computer to terminal in a few seconds. 


REMOTE PROCESSING APPLICATIONS 


In this type of application, data entered from a terminal is 
processed by system programs available under the operating 
system, and results are returned later by the computer. 
Unlike the applications already described, this requires no 
interaction between the separate terminals, and there is little 
sharing of common data files among a group of users. 
Instead, each terminal user has the impression that he is the 
sole user of the computer. 





Text Editing 


In this application, the user can enter, modify, and print 
textual material. The IBM 2740 Communications Terminal 
(Figure 6) is often used because it is identical in appearance 
and keyboard touch to an electric typewriter. Secretaries 
can use it off-line as a conventional office typewriter and 
on-line to retrieve form letters or manuscript drafts, modify 
them, and then direct the system to print them. 


Remote Computing 


Here, the user enters computer programs (in contrast to 
data) for later input to any of the language processors avail- 
able under the operating system. The user may build upa 
library of programs, request compilations, receive results or 
diagnostic data, and make program modifications. 


Communication with the computer may be by any ofa 
number of terminals, including the IBM 1050 and 2740 
already described. AT&T TWX (Teletypewriter Exchange) 
service may be employed for remote computing applica- 
tions, with the Model 33 or Model 35 Teletypewriter serv- 
ing as the terminal unit. TWX is essentially a form of dial-up 
teletypewriter service. In the past, this service was used 
mostly for point-to-point communication between TWX 
terminals. More recently, however, TWX has been used to 
access time-shared remote computing centers. 


* * * * * 


Many TP applications do not fit nicely into the foregoing 
categories of data collection, message switching, inquiry, or 
remote processing. These classifications are intended to 
represent general approaches to TP applications, to illus- 
trate the wide range of capabilities in TP systems, and to 
describe certain problems. This background material has 
introduced some communications terminology together 
with a survey of terminal equipment. The next sections 
discuss more TP equipment, programming techniques, and 
access methods. 


More detailed information on terminal devices is con- 
tained in technical reference manuals listed in the biblio- 


graphy. 


SPECIAL CHARACTERISTICS OF TP SYSTEMS 


The reader has probably already noticed two characteristics 
of the input/output data formats that are not very common 
in conventional computer applications. The first is that the 
header portion of a message is in “free form’’; that is, its 
fields are not delimited by specific character positions, as is 
usually the case with unit records. The reason for this is 
that Teleprocessing systems must be designed to accom- 
modate the people using them, even at the expense of added 
programming complexity or decreased system efficiency. 
Since it is easier for a person to enter a series of symbols 
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than it would be to enter a fixed number of actual destina- 
tion codes, the message header is designed for user, as 
opposed to programmer, convenience and efficiency. 


A second characteristic of TP systems is that message 
lengths are highly variable. In message switching, for exam- 
ple, short messages containing just a few words must be 
processed with long messages containing thousands of char- 
acters of text. The program design must accommodate such 
variations with flexibility and efficiency. This is in contrast 
to the more rigid record sizes found in a majority of off-line 
computer systems. 


Unlike conventional batch-job applications, many TP 
applications never actually end. At the end of each day’s 
operating period, messages still are queued for transmission, 
and the job is never completed. Instead, a “closedown”’ is 
performed to temporarily discontinue processing until a 
“startup” is initiated the next day. 


Another characteristic of message switching and most 
other TP applications is the fact that, because the job is 
never actually completed, it is not possible simply to do a 
rerun in case of a system error. Instead, vital system status 
data is recorded at “checkpoints” so that job steps may be 
restarted in case of error. Checkpoint/restart procedures 
are complicated by the fact that a TP system is seldom 
totally idle and, as a consequence, it is difficult to record 
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the exact status of the many concurrent tasks in operation 
at any instant. Yet the importance of checkpoint/restart 
procedures is apparent since users are heavily dependent on 
the reliability of the central system. 


Another point demonstrated by such a relatively simple 
application as message switching is that the loads placed on 
the system are unpredictable. At some times the system 
load is light; at other times the demand for processing time 
and storage space is substantially greater. The loading is 
determined by the external operating environment and can- 
not be dictated by the computer. Instead the programming 
system must have considerable agility to be able to acquire 
system resources when needed, yet not continually monop- 
olize valuable computer facilities in anticipation of worst- 
case contingencies. 


One final TP characteristic that message switching demon- 
strates is the problems of debugging the user-written control 
programs. How can peak load conditions be simulated? 
How are bugs associated with complex timing or queuing 
conditions detected? When the system is “down” because 
of equipment malfunction or program error, how are the 
users informed? When the system is restarted, what data, if 
any, has been destroyed? Who is affected by the loss? 
Questions like these give some idea of the problems associ- 
ated with the designing and testing of TP programs. 








This section describes the basics of TP equipment. It is 
organized around the primary requirements of a TP system: 


Communication networks 
Character codes 

Error detection 
Transmission control 


Terminal control 


COMMUNICATIONS NETWORKS 


Communications networks are composed of channels (also 
called circuits or lines). There are basically two types of 
networks: switched and nonswitched. 


A switched network is one in which connection between 
a terminal and a computer is made through common-carrier 
exchange equipment. Dialing establishes a connection, and 
the connection is maintained only while transmitting data. 
If the computer is equipped with an automatic calling facil- 
ity, it can, under program control, issue a sequence of dial- 
ing digits. Otherwise, manual dialing is used at either the 
terminal or the computer. Another available facility is auto- 
answering whereby the answering location (the called loca- 
tion) automatically responds to the originating location (the 
calling location). There is also a provision at each location 
to change the mode of transmission between talk mode (for 
normal voice communication) and data mode (for transmit- 
ting data). 


A nonswitched network is one in which the lines con- 
necting the computer and terminals are permanently estab- 
lished. These do not require dialing and are available for 
use at any time. They are also known as private or leased 
lines since they are reserved for the exclusive, private use of 
one customer and are leased from the common carrier on a 
contract basis. 


A communications line can be further classified accord- 
ing to the direction in which it communicates data: 


1. A line that can transmit data in only one direction is 
a simplex line. A terminal that only sends input data 
to a computer is termed send only, and a terminal 
that only receives computer output is termed receive 
only. 


2. A line that can transmit data in either direction, but 
not simultaneously, is called half-duplex. A terminal 
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on such a line is in either send mode or receive mode 
(but not both). 


3. A line that can transmit data in both directions at the 
same time is called duplex. A terminal on such a 
line can send and receive at the same time. 


Transmission Speed 


A line can also be classified by its speed; that is, the max- 
imum rate at which it can accommodate data transmission. 
This quality is sometimes expressed in terms of bandwidth: 
the range of frequencies the line can accommodate. 
Directly related to the bandwidth of a line is its speed capa- 
bility in bits per second. A character is represented on a 
communication line by a series of bits, the number of which 
depends on the transmission code and transmission tech- 
nique used. Each bit requires a specific amount of time on 
the line, and the bit rate, expressed in bits per second, is the 
reciprocal of this amount of time. 


Another term frequently used to express speed capability 
is the baud. To properly define this term would require a 
more detailed discussion of transmission techniques than is 
warranted in a publication of this scope. Because the numer- 
ical value of a line’s speed in bauds and in bits per second is 
sometimes the same, the two terms have come to be used 
interchangeably. This is, however, incorrect, as the two 
terms are not synonymous. The term baud should be 
avoided, and the more useful bits per second used instead. 


Many different types of channels are available, in a vari- 
ety of speed capabilities. For data communications pur- 
poses they may be classed as follows: 


1. Narrow-band, or low-speed, lines have a bit rate of up 
to 300 bits per second (bps). Included in this category 
are telegraph-grade and sub-voice grade lines, which 
refer to the lower speeds in the narrow-band range. 


2. Voice-band, or voice-grade, lines operate at medium 
speeds—over 300 bps. The term voice-grade is used 
because this range can be accommodated by the cir- 
cuits used for ordinary voice communication in the 
audio range (frequencies that can be heard by the 
human ear). 


3. Wideband, or high-speed, lines operate at bit rates of 
about 18,000 bps and higher. These lines often are 
used for transmitting data directly from one computer 
to another at very high speeds. 
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Generally, higher line speeds require more sophisticated and 
expensive common-carrier facilities, and the tariffs for their 
use are correspondingly higher. 


Two other measures of a line’s speed are useful: The 
character rate equals the bit rate divided by the number of 
bits per character, and is expressed in characters per second. 
To express speed in words per minute requires that word 
be defined. In communications usage a word is usually con- 
sidered to be six characters: five symbols followed by a 
space character. Using this convention, 


bits per second 


bits per character LO 


words per minute = 


Note that the foregoing discussion pertains to the rated 
capacity of a communication line. Actual data rates will be 
lower; they depend on the sending speed of the terminals 
attached to the line, and, for keyboard-entered data, upon 
the keying speed of the terminal operator. 


Equipment Connections 


Data processing equipment is connected to a communica- 
tions network by a device that goes by many names, includ- 
ing modulator and demodulator unit, mod/demod, modem, 
subset, and data set. Certain trade names such as Data- 
Phone (an AT&T trademark) also are used. Whatever its 
name, this device provides an interface or common bound- 
ary between data processing equipment and communica- 
tions equipment. In this publication, the term modem is 
used. 


Modems vary considerably according to the types of net- 
works, data rates, and forms of signalling employed. How- 
ever, they all are designed to convert the binary signals of 
business machines to the transmission frequencies of 
communications equipment and vice versa. For example, 
an IBM 1050 terminal sends a sequence of bits to a modem 
which converts (that is, modulates) it to an equivalent 
sequence of transmission signals. At the receiving computer 
site, another modem reconverts (that is, demodulates) this 
signal sequence into the same bit sequence originally sent 
by the terminal. 


The electrical interface between data processing equip- 
ment and communications equipment is defined by industry 
standards. This fact, coupled with the fact that the 
modulation/demodulation process is in most cases “trans- 
parent” to the telecommunications equipment, means that 
in actual practice, there is little need for system designers 
and programmers to become intimately familiar with modu- 
lation techniques. 


16 


CHARACTER CODES 


Teleprocessing systems use several different methods to 
represent data characters. Some of these were originally 
designed for communications equipment; others are derived 
from codes used for representing data on computer 1/O 
equipment. The codes differ primarily in the number of 
bits used to represent the characters (called the Jevel of the 


code) and in the particular patterns of bit settings used to 
represent the characters. A coded character may be clas- 
sified as either a graphic character, representing a symbol, 
or a control character, controlling a terminal function. The 
number of different characters that can be coded is depend- 
ent on the level of the code and on the coding scheme 
employed. 

In some codes, often termed shifted codes, certain con- 
trol characters are used to specify the way in which follow- 
ing graphic characters are to be interpreted. With such a 
use of control characters, called a shift convention, each bit 
pattern can represent more than one symbol. Thus, in this 
type of code, the number of characters that can be repre- 
sented is greater than the number of distinct bit combina- 
tions. However, these codes have the disadvantage of some- 
times requiring two coded characters (a shift control char- 
acter and a graphic character (to represent one symbol. 
Some five-level telegraphy codes have shift conventions for 
figures and letters, and some seven-level codes have such 
conventions for upper and lower case. 


Baudot Code 


An important shifted code is the widely used Baudot code, 
named in honor of a pioneer French telegrapher. It is a 
five-level code and can thus represent 2° = 32 different 
combinations (see Figure 7). Since this is not sufficient to 
represent the alphanumeric data (the 26 letters of the alpha- 
bet, 10 digits, plus special characters such as +, -, $) occur- 
ring in most message texts, Baudot codes are interpreted 
two ways depending on the shift status of the printing 
mechanism. 


When in letters shift (LTRS ) the codes represent letters; 
when in figures (FIGS) the codes represent digits and spe- 
cial symbols. Four character codes are given the same inter- 
pretation independent of shift position: blank (no bits), 
delete (all bits), carriage return (CR), and line feed (LF); 
two characters are used to change shifts (LTRS and FIGs ). 
The result, as can be seen in Figure 7, is that Baudot code 
can accommodate 2 (25) - 6 = 58 different characters. 
Baudot code does not have error checking, and terminal 
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Figure 7. Baudot Code 





control is achieved by special sequences of characters. 
Thus, for example, the sequence FIGS H LTRS is com- 
monly used to indicate the end of a message (often abbre- 
viated as EOM ). 


USASCII 


The absence of checking and the limitation on the number 
of characters representable in Baudot code have led to in- 
creasing use of a code termed ASCII or USASCII (United 
States of America Standard Code for Information Inter- 
change). This is a seven-level code, thus providing 27= 128 
possible characters. An eighth parity bit, though not part 
of the standard, is often associated with the seven data bits. 
The USASCII character set consists of 34 control codes 
and 94 text characters including the letters of the alphabet 
in both upper and lower case, the 10 digits, and anumber of 
special characters (see Figure 8). 


EBCDIC 


Another widely used code is EBCDIC (Extended Binary 
Coded Decimal Interchange Code). This is an eight-level 
code and, as the name implies, is widely used for exchang- 
ing data between computer systems. It has 256 possible 
combinations: 17 of these are used for control purposes, 
96 are used for text characters, and the remaining code 
combinations are unassigned (see Figure 9). 


In addition to the dissimilarity of code structure between 
the EBCDIC and USASCII codes, their collating sequences 
(ordering of the binary representations of the characters) 
differ. In the USASCII collating sequence, for example, 
digits precede letters; in EBCDIC , digits follow letters. 
Thus, the characters A, B, C, 1, 2, 3 are in sequential order 
(ascending) in EBCDIC, but not in USASCII. 


Many TP systems accommodate several different codes 
by providing for code conversion, or translation, between 
different code representations. For example, data may be 
received in one transmission code, converted to a code suit- 
able for computer processing, and then converted to still a 
third code suitable for transmission to an output terminal. 


Translation tables are used to convert from one character 
code to another, and special computer instructions often are 
available to utilize such tables automatically. Another aid 
for conversion to and from 5-bit codes is incorporation of a 
shift bit along with the five data bits to form a 6-bit code, 
thus eliminating the need for explicit shift characters. This 
considerably simplifies internal processing since all char- 
acters then are represented by a single byte (8 bits) rather 
than sometimes requiring a pair of bytes. 
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ERROR DETECTION TECHNIQUES 


Communications circuits are subject to a variety of environ- 
mental conditions not encountered in a computer system. 
Some of these conditions may create electrical “noise” in 
the circuit and cause unpredictable errors in transmitted 
data. There are many sources of noise, such as nearby high 
voltage circuits, cross-talk (accidental induction between 
circuits), and impulses caused by lightning strikes. Requisite 
to satisfactory system performance is the ability for such 
transmission errors to be detected and, where possible, 
corrected. As common-carrier facilities do not generally 
provide such a capability, the burden of error detection and 
correction falls upon the computer and terminal equipment 
at either end of the communication channel. 


Error detection is usually performed by means of some 
redundant data in the transmitted message. Checking can 
be done at the character level and/or at the message level. 
Character checking is usually performed with the addition 
of an extra bit to the data bits comprising the character 
code so that the total number of | bits in any character is 
always odd (or always even). The receiving unit checks each 
character for proper parity. Such checking is identical to 
that performed in many computer systems, and, since the 
character is often depicted as a vertical set of bits, this 
method is called vertical redundancy checking (VRC ). 


While VRC techniques detect all single bit errors (picking 
up or dropping a single bit), it does not detect double 
errors. A form of coding called fixed count coding accom- 
plishes more thorough checking at the expense of slightly 
less efficient transmission and somewhat more sophisticated 
checking equipment. The term fixed count code is derived 
from the fact that for any character a fixed number of bits 
are always one and the remaining bits are always zero. A 
common example of fixed count coding is the “4 of 8” 
code, in which every character has exactly 4 bits set to one 
and the remaining 4 bits set to zero. Two things should be 
noticed: more error conditions are detected, but there are 
only 70 valid character representations, whereas a VRC 
code using the same number of bits has 128 valid characters. 

Checking at the character level detects many errors. 
However, it does not detect multiple bit errors or missing 
characters. To overcome these deficiencies, it is useful to 
accumulate parity longitudinally along a message as well as 
vertically across characters. In this technique, called longi- 
tudinal redundancy checking (LRC), a special check char- 
acter is inserted at the end of a message or message block 
so that the total of the settings along the same bit position 
in all characters is always odd. LRC checking thus detects 
missing characters. Again, more sophisticated terminal 
equipment is necessary both to generate LRC codes when 
sending and to check LRC codes when receiving data. 


A more thorough checking technique accumulates check- 
ing data both vertically across characters and longitudinally 
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along messages. These cyclic codes require more elaborate 
equipment to generate and test them. A type of cyclic 
checking is used on most IBM direct access storage devices. 


TRANSMISSION CONTROL 


Transmission is controlled by devices called transmission 
control units (TCU’s). These provide a control interface 
between the computer and the communications network. 
Depending on the number and speed of lines to be serviced 
several types of units are available. In the IBM System/360, 
for example, up to eight of the following types of trans- 
mission control units may be connected to a multiplexer 
channel: 


> 


2701 for up to 4 low speed lines 

2702 for up to 31 low speed lines 

2703 for up to 176 low speed lines 

7770 for audio response on up to 48 lines 
7772 for audio response on up to 8 lines 


One of the most important functions performed by the 
TCU is coordination of the input and output of data to 
and from the communications network. Two modes of 
transmission are widely used. Start-stop mode, commonly 
used on low speed networks, delimits each character with 
special control bits denoting the beginning and the end of 
the sequence of bits forming a data character. Synchronous 
mode transmission, commonly used on medium and high 
speed lines, establishes a timing synchronization between 
sending and receiving equipment before sending a stream of 
characters. Start-stop mode is simple and inexpensive but 
requires extra bits to control each transmitted character. 
Synchronous mode requires more sophisticated electronics 
in the terminal equipment but more efficiently utilizes the 
communications facility. 


A specific example will illustrate how a TCU operates in 
start-stop mode. First assume a number of low speed lines 
(say 30) attached to the same TCU. The TCU contin- 
uously apportions its time to each of the lines in turn. In 
the case of input data, the TCU continually monitors the 
line for an indication that a new character is about to start. 
This is indicated by a transition of the line from a mark 
(one or more | bits) status to space (a O bit) status. Then 
an oscillator operating at the line’s bit rate causes the TCU 
to sample that line during each successive bit time. These 
line samples (either 0 or 1 bits) are assembled serially-by-bit 
in a shift register until the required number of samples and 
a stop bit have been accumulated into a character. The 
character is then stripped of start/stop bits and placed in 
another register to await transmission (in a parallel-by-bit 
manner) to the computer via the multiplexer channel. 
Meanwhile the TCU is looking for the start bit of the next 
character. 





Output is performed in a similar fashion. A character is 
received from the computer and, after having start-stop bits 
added, is moved in parallel to a shift register which shifts 
the bits onto the line at the proper bit rate. 


Depending on the particular types of lines involved, the 
TCU also has other functions. It may perform validity 
checks on incoming data, delete certain “idle” characters 
from the data stream, and detect shift codes and automat- 
ically control shift status (upper case or lower case) of a 
terminal. The TCU performs all these functions without 
program intervention, on a number of lines concurrently. 
As far as the programmer is concerned, the TCU presents 
much the same appearance as any other control unit (for 
example, a card reader) attached to the multiplexer channel. 


The computer must assemble incoming characters into 
messages, translate codes, and edit messages prior to per- 
forming conventional processing operations. For output, 
it performs similar operations: converts codes, inserts ter- 
minal selection and control characters, and passes the out- 
going message, character by character, to the TCU via the 
multiplexer channel. 


TERMINAL CONTROL 


Most computer input/output equipment uses separate paths 
(or lines) to transmit data and to indicate control functions. 
Communications equipment is connected to a computer 
with one or (in the case of duplex transmission) two 
lines. Consequently, conventions must be established to 
identify and distinguish between the data and the control 
information that must be transmitted over the same com- 
munications channels. Several factors are involved. 

A first factor is that, unlike other I/O devices, a terminal 
often is not continuously connected to the system. The 
terminal user may dial the computer to submit input, or the 
computer may establish contact with the terminal (via the 
automatic calling facility described earlier) prior to trans- 
mitting output data. Although much of this is handled by 
automatic calling and answering, the system must still 
initiate and confirm the communication link to the ter- 


minal. This introductory communication is sometimes 
called “‘handshaking.” 


A second factor is that several terminals may be attached 
to the same private line. This reduces the cost of the com- 
munication facilities but requires additional control conven- 
tions to determine which of the several terminals is to send 
or receive data. Terminals designed to operate on multi- 
point lines (those connected to multiple terminals) have 
special control units or “stunt boxes” (a telegraphy term) 


that provide this capability, and operate in one of two 
modes: control or text. When in control mode, a terminal 
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interprets received characters as special control codes; when 
in text mode, a terminal treats most characters as normal 
textual data. 


In the case of input, the computer sends one or more 
control characters putting all terminals in the control mode 
and then, using polling characters, invites a specific termi- 
nal to send any messages it may have. Ifa polled terminal 
is ready and has a message to send, it reverts to text mode 
to transmit the message. Other terminals on the same line 
remain dormant. A special code or sequence of codes indi- 
cates the end of message ( EOM) and returns the terminal to 
control mode. If a polled terminal is ready but does not 
have a message to send, it usually responds with a code 
indicating its ready status. If the computer does not receive 
any response (a text message or status code) within a brief 
time, then the terminal “‘times out” and is considered not 
ready (for example, is off-line). 


Output from the computer to the terminal is controlled 
in a similar fashion. The computer first addresses (attempts 
to select) the receiving terminal by means of a control 
sequence or, in telegraphy terms, a call directing code 
(CDC). If the terminal is ready to receive, it responds to 
the computer with an acknowledge character, and goes into 
text mode. The computer then transmits the output 
message. 


A final elaboration on the line control methods is con- 
cerned with error correction. With some types of terminals, 
transmission can be error checked as discussed earlier. 
Following input of a message from terminal to computer, 
the computer may respond with control codes indicating 
that transmission was correct and that the terminal should 
go ahead and transmit the next message. Or, if an error has 
been detected, the computer may respond with control 
codes to request retransmission of the message. For some 
terminals, retransmission requires manual intervention; for 
others, it is performed automatically. 


For output from the computer to a terminal, a similar 
process is used. The terminal performs error detection, 
and, following receipt of a message, sends a control 
sequence to the computer indicating either correct transmis- 
sion or detection of an error. In the former case, the 
computer will start sending the next message; in the latter, 
the computer usually retransmits the same message. 


* * * K * 


This section has introduced some of the more important 
characteristics of commonly used communications equip- 
ment. More detailed information may be found in the tech- 
nical reference manuals listed in the bibliography. 
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Since programming techniques vary considerably according 
to specific equipment configuration and processing require- 
ments, it is difficult to give a concise description of general 
TP programming techniques. This section describes some 
programming functions that have unique characteristics in 
TP systems: 


e allocation and scheduling 
e buffering 

@ queuing 

@ message control 


@ message processing. 


ALLOCATION AND SCHEDULING 


How the total resources (processing time, main storage, I/O 
paths, etc.) of a TP system are apportioned is termed alloca- 
tion. When these resources are apportioned is termed sched- 
uling. In early systems, the only allocation necessary was 
the assignment of storage areas for program routines, 
constants, working storage, and I/O areas. Such allocation 
was planned ahead of time by the programmer and then 
specified at the time a program was assembled. This alloca- 
tion is termed static since, once specified, it cannot be 
changed without reassembling (or recompiling) the program. 
In later systems, the allocation of storage was deferred until 
the time the program was loaded. This enabled separately 
compiled programs to share common data and I/O areas, 
but once the program was loaded, no further allocation was 
possible. More recently, responsibility for the allocation of 
portions of storage and the assignment of 1/O units was 
undertaken by operating systems, some of which have been 
extended to the point where they now control all storage, 
1/O units, and data channels. Not only are more resources 
allocated in a more flexible manner, but, wherever possible, 
allocation is deferred until the resources are actually needed. 


In a similar manner, jobs that once were manually sched- 
uled for execution later were scheduled by the operating 
system, but only one job was initiated at a time. Once 
started, a job ran to completion or until an error was detected 
or a time allotment expired. The next advance in the 
evolution of job scheduling techniques was initiation of 
several jobs concurrently and dynamic interleaving of 
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their executions. This interleaved execution of several pro- 
grams is termed multiprogramming, while the sharing of 
computer time is quite naturally called time-sharing. 


Thus, not only has the range of system resources alloca- 
ble been increased, so that now even central processing 
unit time can be allocated; the time range over which they 
can be allocated has been increased as well, so that some 
resources now can be allocated during program execution. 


There are several reasons for this increased generality in 
scheduling and allocating resources: 


e Efficiency is increased since resources that might other- 
wise be idle can be used by other tasks. 


e Flexibility is improved since the system can readily 
adjust to varying demands for resources. 


e Growth potential is enhanced since added storage or 
other facilities can be readily accommodated without 
extensive reprogramming of the scheduling and allo- 
cation routines. 


e Response rates are improved since tasks can progress in 
in parallel rather than serially. 


These factors, fundamental to any computer system, are 
even more vital to a TP system in which the demands for 
system resources vary dynamically and unpredictably. 
Designing a good allocation and scheduling system for the 
TP environment proves to be an extremely difficult under- 
taking. Some of the factors that must be considered 
include: 


1. Which responsibilities are reserved for operating per- 
sonnel, and which are handled automatically by the 
system? The man-machine tradeoffs are necessary to 
permit human intervention and control and yet not 
hinder the trivial administrative functions best per- 
formed automatically by the system. Too much 
human intervention leads to inefficiency and human 
error; too little human intervention leads to loss of 
control and of adaptability to changes in processing 
priorities. 

2. Which allocations are static and which are dynamic? 
Some resources must be reserved for use by the 
operating system itself. In addition, it is often con- 
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venient to dedicate certain system units to specialized 
functions. On the other hand, some units must be 
statically assigned to a pool of resources from which 
the system may dynamically draw to satisfy pro- 
cessing needs. 


3. How should resources be divided into useful units for 
purposes of allocation? The larger the number of 
units, the more flexibly and efficiently they may be 
utilized. Unfortunately, however, the greater atten- 
tion that must be devoted to scheduling and account- 
ing for the resource units may far outweigh the 
improved utilization of the resource itself. For 
example, core storage is often partitioned into a 
number of units, which are allocated only in whole 
multiples. The larger these units, the greater the 
possible “trim loss” (the portion of the unit that is 
unused, where only a portion of a unit is needed). 
The amount of trim loss must be weighed against the 
additional table space and supervisor overhead that 
would be entailed if storage were partitioned into 
more, but smaller, allocation units. 

4. Finally, what is the proper relationship between allo- 
cation and scheduling? That is, should scheduling be 
a function of resource allocation, or should it be the 
other way around? There is no one correct answer to 
this question; in practice, the distinction becomes 
blurred. To achieve the theoretical maximum 
resource utilization would require almost continuous 
reallocation; the supervisor time required for this is 
prohibitive. The designer of a programming system 
must discover the optimum balance between efficient 
utilization and minimal supervisor time devoted to 
allocation. 


The treatment of allocation-scheduling interaction has a 
profound influence on the power and efficiency of any 
modern operating system. Some allocation and scheduling 
functions are peculiar to the TP environment, and it would 
unnecessarily burden a general purpose operating system to 
accommodate them as a standard capability. As a conse- 
quence, specialized modules are often available to encom- 
pass those additional functions. The most important of 
these functions are the buffering, queuing, and terminal 
control functions which are discussed below in more detail. 


BUFFERING 


A buffer is astorage area that temporarily stores data during 
transmission from one device to another. Buffers are used 
to compensate for differences either in data rates or in times 
of occurrence of related events. An example of the first use 
occurs in a data entry application in which incoming char- 
acters are collected in core storage buffers. Often, as each 
buffer becomes filled with data, the data is written from 
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this buffer to another buffer area in a disk file. The core 
buffer compensates for the difference in data rates between 
a communications terminal (typically 15 characters per 
second) and a computer data channel (typically over 
150,000 characters per second). 

An example of using a buffer to compensate for time dif- 
ferences occurs frequently in message switching applica- 
tions. A message is received and collected in a disk buffer 
area until the destination terminal becomes available. The 
buffer is used to compensate for the difference in time 
between receiving a message and forwarding it to the desti- 
nation terminal. 


The programming techniques used to assign and control 
allocation of buffer storage, called buffering, are a critical 
factor in the design of TP systems since there are vast differ- 
ences both in data rates and in the time intervals between 
events. As mentioned earlier, a third complicating factor is 
that in many TP applications (message switching being a 
prime example), both data volumes and message lengths 
may vary widely and at unpredictable times. 


Buffer Allocation 


Buffers generally must be maintained on several different 
storage devices, and a system design objective is to effi- 
ciently utilize each of these. With core and disk buffers the 
following questions arise: what should be retained in core, 
what should be moved to the disk, and when should this be 
done? If core buffers are not made available for reuse 
promptly, there may be no place left for arriving input data. 
Loss of data is possible in a TP system since much simulta- 
neous data input may be in process at any instant and the 
program does not have the same close control over terminal 
input as it does over input from tape or disk units. Other 
consequences of having insufficient core buffers or of not 
making them available promptly are a reduction in system 
operating efficiency and a slowing of terminal responses 
while waiting for the buffer congestion to clear. 


In many conventional computer systems, buffering is 
used to obtain overlap of I/O operations with computing. 
In the simplest case, data is moved from a work area to an 
output buffer; then data is moved from an input buffer to 
the work area; and, finally, while the computer is processing 
the record in the work area, data channels are concurrently 
transmitting the output buffer and refilling the input buffer. 
The amount of read/write/compute overlap depends on the 
balance between these three concurrent operations. Elab- 
orations of this approach involve using multiple buffers, 
performing the processing in the buffer rather than in a 
work area, and using a group of buffers (called a buffer 
pool) to supply buffer areas dynamically rather than having 
fixed buffer assignments. Each of these techniques provides 
for greater flexibility and more efficient utilization of 
buffer storage. 








Buffer pools have an added advantage in TP systems. 
Because record sizes (i.e., message sizes) are highly variable, 
it would be wasteful of storage space always to assign for 
each message, regardless of length, a single buffer area large 
enough to hold the largest expected message. Instead, each 
message is contained in a series of buffers that are allocated 
dynamically as needed. Requiring the buffers containing 
the segments of a message to be in contiguous storage loca- 
tions would unduly restrict buffer utilization. Each buffer 
is therefore allocated without regard for the location of 
previously allocated buffers, but is linked to the next buffer 
by chaining: each buffer contains the storage address of the 
buffer containing the next segment of the message. (Some 
convention is used to identify the last buffer in a chain; 
often, a zero chaining address signifies this.) Thus, although 
the segments of a message are contained in buffers dispersed 
throughout a buffer pool, a computer or channel program 
can access the entire message by progressing through the 
chain sequentially. When the message contained in the 
buffer chain has been processed, the buffers are returned to 
the chain of available buffers. This is easy to do since only 
the first of the newly available buffers need be chained to 
the chain of available buffers; the remaining buffers are, by 
their association with the first buffer,automatically returned. 


Buffering Considerations 


The size of the buffer pool and the size of the individual 
buffers depend on a number of factors, including the 
average and peak amount of input/output data, the ratio of 
input volume to output volume, the data rates of the TP 
equipment, the amount of storage available, and the form 
of allocation used with secondary storage units. 


The program must dynamically adjust its operation to 
meet unpredictable changes in the operating environment. 
To overdesign a program to handle the worst possible case 
as the typical situation leads to excessive waste of expensive 
system resources. Conversely, to design a program without 
recognition of every infrequent, yet possible, situation is 
equally undesirable. Programs must be designed to effi- 
ciently handle the average case and yet manage to cope with 
the worst situations. Some parameters must be changed 
dynamically ; others must be established at system generation 
time to “tune” the system to the typical load profile of the 
specific TP environment. 


QUEUING 


A queue is a waiting line, and the term queuing is used to 
denote the programming techniques employed to control 
transactions awaiting servicing by some computer facility. 
Queues are a consequence of items arriving for service at an 
unpredictable rate. If each item is serviced before the next 
item arrives, then no queue develops. Conversely, if the 
arrival rate continually exceeds the servicing time, then an 





infinitely long queue develops. The most common queuing 
situation is that in which, although the average arrival rate 
is less than the service rate, intermittent surges in the arrival 
rate cause a queue to form. 


Like buffering, queuing is a function which, though 
present in some conventional computing systems, assumes 
far greater importance in the TP environment. In some 
conventional systems, especially those with both multi- 
programming and direct access storage devices, queues may 
develop when several programs make requests for data 
faster than the device can access the data. A queue of file 
requests is formed, and some form of queue management is 
used to determine which item in the queue is to be serviced 
next. A number of different techniques are possible. 


Sequence Handling 


Probably the most common queuing technique is to service 
the queued items in the sequence that they arrive. This 
method, sometimes called FIFO (first in, first out), is 
certainly the simplest to implement. However, other 
approaches may be more efficient. For example, some 
situations may require a LIFO (last in, first out) rule. This 
approach, often called a “~pushdown” or “stack” in computer 
terminology, is frequently used in performing arithmetic 
operations. In the case of a disk storage request queue, 
access times might be reduced if the current position of the 
access arm is noted and the queue is scanned for the item 
requiring the shortest motion of the access mechanism. In 
this case, safeguards must be established to prevent some 
item in the queue from being delayed an intolerable time 
because it is continually bypassed in favor of other items 
closer to the current position of the access mechanism. 
Other methods of queue management would be to assign 
priorities to the queued items depending not on the 
servicing device, as in the previous example, but on the 
resources needed to process the queued item, or to give 
favor to the oldest items in the queue, or to give output 
priority over input operations. 


The purpose of the foregoing discussion is to illustrate 
that although the concept of queuing is simple, the tech- 
niques used to process queues can have a significant influ- 
ence on overall system performance. This is especially true 
of TP systems, in which queues are very common, because 
continually varying demands are being made for a number 
of facilities and because unpredictable utilization of commu- 
nication lines inevitably causes temporary queuing of output 
messages. 


Now, whereas buffering is frequently accommodated in 
primary storage, it is more common to relegate queues to 
secondary storage devices. Control information containing 
enough data for queue management is retained in primary 
storage. The queues then can be rapidly scanned to deter- 
mine the next item to be serviced. When ready for servicing, 
the item can be retrieved from secondary storage. As with 
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buffering, the TP control program must provide for assigning 
and reclaiming storage areas allocated to queuing functions. 
In addition, provision must be made to recognize when 
queues are building up to critical lengths and to modify 
normal program execution to give top priority to reducing 
the backlog of queued items to a safer level. 


Problems in Queuing 


Queuing in the TP environment creates some special prob- 
lems not encountered in conventional computer systems. 
One problem is that a message may belong to more than one 
queue at the same time. Consider the case of a multiple- 
addressed message in a store-and-forward switching applica- 
tion. It would be wasteful to duplicate the entire message 
in the queue for each destination. Instead, only one copy 
of the message is queued, but control entries referencing the 
message are put in the pertinent output queue control areas. 
The same message text can then be directed, at different 
times, to the various destinations. 


Another queuing facility necessary in many TP systems 
also can be illustrated by an example from the message 
switching application. Suppose a user has a very important 
message to send, and the system is loaded to the level at 
which transmission delays of perhaps one-half hour are 
occurring. The user desires to have the system send this 
message to its destination ahead of other items queued for 
the same destination. He can do this by inserting a priority 
code in the message header. The queue management routine 
recognizes this code and gives the message priority treat- 
ment when scanning the output queue. An elaboration of 
this approach is to have a number of levels of priority, and, 
in fact, most TP systems do provide for multiple priority 
levels. 


In summary, these examples illustrate that TP systems 
must have queuing capabilities far beyond those found in 
conventional systems. It is seen that the flexibility of the 
queuing techniques employed can enhance the use of the 
system. In addition, the efficiency and modularity of the 
queuing techniques can have a substantial impact on overall 
system efficiency. 


MESSAGE CONTROL 


This section considers the programming aspects of the TP 
equipment described in the section, Teleprocessing Equip- 
ment Characteristics. It assumes that all communication 
channels are half-duplex and that only terminals of the same 
type are connected to any one line. 


Once the line configuration is determined, information 
regarding the detailed characteristics of different types of 
terminal units must be associated with specific lines. Each 
device has an I/O module containing model channel pro- 
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grams that are used when READ/WRITE routines are in- 
voked from macro instructions embedded in the user prob- 
lem program. In addition, associations between lines and 
control units must be established. This kind of TP config- 
uration information is established at the time a system is 
initially generated and need be modified only when the 
configuration is changed. 


Further information is provided through declarative 
macro instructions contained in a user program. These 
determine, at assembly time, the allocation of core storage 
space for each type of communication line to be used. For 
example, such items as buffer pool size, buffer size, and 
type of buffering are indicated together with information 
relating which lines are to share common control areas. 
Another kind of information, also provided through dec- 
larations, defines the structure of the lists used for such 
functions as polling, addressing, calling, and answering. For 
example, a polling list for each line indicates the sequence in 
which the terminals on that line are to be polled. Con- 
siderable flexibility is usually possible. For instance, the 
same polling code can appear several times in the list to 
cause the corresponding terminal to be polled more fre- 
quently than the others. 


Information Handling 


Once presented with the necessary declarative information, 
the TP control program accesses terminal units in such a 
manner that the programmer is relatively unaware of the 
details of the terminal operation. For example, upon 
receiving control from a READ macro instruction executed 
in a user program, the control program will: 


1. Send a control character placing all terminals on the 
line in control mode; 


tr 


. Send the polling characters for the designated ter- 
minal; 


3. Wait for a response indicating whether the polled ter- 
minal has input ready to send; 


4. Receive the message, test each block of the message 
for errors, and request retransmission of any block 
containing errors; 


5. Upon completion of input from the polled terminal, 
poll another terminal on the line. 


This example is considerably simplified. In reality, the 
program performs many other functions, and numerous 
options are available to the problem programmer. 


The previous section outlined the programming tech- 
niques used to allocate buffer storage and to read and write 
messages. If queuing is desired or if records are to be ref- 
erenced at the logical level via GET/PUT -type access, further 
facilities must be added. 














Message Routing 


Routing of messages in accordance with data contained in 
their headers is a function common to many applications. 
Here the programmer must establish terminal tables relating 
each symbolic terminal identifier to the terminal it rep- 
resents. This simplest case must usually be extended to 
accommodate group addressing and distribution lists, by 
which several terminals can be represented by the same sym- 
bolic identifier. For example, in the case of all those branch 
locations that provide a particular service, it is more con- 
venient and less error prone to reference the entire group 
by a single symbolic name. 


In many applications, messages are routed not to another 
terminal but to one of several processing programs. Here 
the TP routing data is used as a transaction code to cause 
control to pass to the proper processing routines. The 
programmer employs essentially the same technique used 
for message routing, the only difference being that the des- 
tination location is not a terminal address but the symbolic 
entry point of a routine that is to receive control when the 
message is ready for processing. 


An example is an inquiry system: inquiry messages 
arrive in the transmission code of the type of terminal from 
which they were entered, and are usually translated to a 
character code (e.g., EBCDIC ) suitable for processing. Sim- 
ilarly, reply messages generated in the processing code are 
converted to the transmission code of the destination ter- 
minal. Code translation is usually performed by a table 
look-up technique in which, for each character in succes- 
sion, the original code representation of a character is 
applied as an index value to the beginning of the translation 
table, to find the corresponding new code representation. 


In the IBM System/360, this translation from one char- 
acter code to another is greatly facilitated by an instruction 
designed for this purpose. If new terminal types are added 
or different translations are desired, it is easy to accommo- 
date them by adding another table or by modifying an 
existing table. The programmer need not be concerned with 
the control codes used by each terminal, since, as explained 
earlier, terminal control and error checking are automat- 
ically performed by message control routines. 











Message Processing 


Although the message control facilities described above en- 
compass a number of functions common to a wide range of 
TP applications, they cannot accommodate all requirements 
of all applications for which they are used. Even if these re- 
quirements could be adequately defined, a general purpose 
program capable of fulfilling them would require a machine 
configuration far beyond that required for any specific 
application. Therefore, the key to generalizing TP programs 
is knowing the tradeoff between technical feasibility and 
general utility. Some functions must be provided in a basic 
programming package, additional functions may be provided 
in an extended package, and some functions of value to 
some users cannot be accommodated without penalizing the 
majority of users. 

Message processing functions unique to a specific appli- 
cation are programmed by the user. In many applications, 
the programmer can, through use of message control rou- 
tines, construct an interface to the communications environ- 
ment such that the message processing routines may be 
designed, coded, and tested without consideration of the 
fact that they will be executed in a TP system. Since the 
application programmer is in effect insulated from the 
environment, he does not need a detailed knowledge of TP 
equipment, programming methods, and testing techniques. 
This fact can result in lowered development schedule time 
and costs. 


* * KF K 


This section has introduced some of the programming tech- 
niques that play important roles in TP systems. The best 
sources of additional information are to be found in the 
reference manuals describing specific telecommunications 
access methods. A list of these is contained in the bibliog- 
raphy of this publication. 
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IBM programming support for TP systems is provided in the 
form of access methods under the Data Management 
portion of both the S/360 Operating System and the S/360 
Disk Operating System. 


The principal function of a telecommunications access 
method is to control the transmission of information 
between a computer and remote TP equipment in much the 
same manner as other access methods support other types 
of input/output equipment. The programmer designs, 
writes, and tests his application routines in the usual 
manner, and he performs input/output operations by means 
of macro instructions supplied by the access method. The 
user may also develop his own macro instructions to replace, 
or augment those supplied by the access method. 


There are two levels of telecommunications access 
methods: one, at the READ/WRITE level, is called Basic 
(BTAM); the other, at the GET/PUT level, is called Queued 
(QTAM). 


BTAM is designed to provide the basic modules for con- 
structing a TP program, including routines for controlling a 
variety of terminal units, communications lines, and trans- 
mission control units. With a minimum of system overhead, 
it not only provides the basic tools to build a sophisticated 
system but also is modified easily to support special config- 
urations not supported by other programming packages. 
BTAM provides the basic capabilities to: 

@ Poll terminals and receive messages, 
e Address terminals and send messages, 
e Dynamically chain input buffers, 

e Dial and answer, 

e@ Detect and correct errors, 

e Write output buffer chains, 


e Perform code translation. 


QTAM has two characteristics that distinguish it from other 
access methods: 


e Scheduling and allocation functions are performed by a 
separate control program within the operating system. 


@ Operations to control and process communications data 
are specified by a unique macro language. 
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QTAM includes the BTAM capabilities mentioned above 
and, in addition, provides extensive queuing facilities. 
QTAM is directly applicable without modification to a 
number of common TP applications, for example, data 
collection and message switching. QTAM provides the 
basic capabilities for: 


e Controlled and automatic terminal polling and message 
input, 


e Controlled and automatic terminal addressing and mes- 
sage output, 


e Input/output buffering, 

e Error detection and checking, 

e Message queuing, logging, and routing, 
e Code translation. 


Figure 10 shows the various types of terminals supported by 
BTAM and QTAM. 


BTAM 


As already stated, BTAM controls terminal input/output 
operations initiated by READ and WRITE macro instruc- 
tions issued in the user’s problem program. The primary 
purpose of BTAM is to provide input/output support at the 
message level under the operating system. As a consequence 
there are really two BTAMs: one for the full Operating 
System (OS) and one for the Disk Operating System (DOS). 
These two versions of BTAM have a similar appearance to 
to the user. The principal external differences are: 


e Audio response equipment ( IBM 7770 and 7772 Audio 
Response Units) is supported only under DOS. 


e Operating systems incorporating BTAM have a minimum 
memory size of 32K bytes for DOS and 64K bytes for 
OS. 


The principal internal difference is that buffers are allo- 
cated to accept a maximum size message under DOS, while 
READ/WRITE _ buffers are allocated dynamically under OS. 
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Figure 10. BTAM and QTAM Device Support 


The use of BTAM is recommended for those systems 1050 terminals, attached to an IBM System/360 by means 

having one or more of the following characteristics: of an IBM 2701 TCU. Assuming one 140-byte buffer for 

each line, and polling and addressing lists each having one 3- 

e A small number (1-4) of communication lines. byte entry for each of the 16 terminals, the total core stor- 

age needed is in the range of 3,000-4,000 bytes for BTAM 

e A requirement for a specialized TP control program. under OS and about 4,500-5,500 bytes for BTAM under 
DOS. 


Storage Requirements 


The primary storage requirements of BTAM depend on the 


particular configuration of terminal equipment, the buffer- Description 
ing requirements, and the macro instructions used. A typ- BTAM facilities must be incorporated into the operating 
ical configuration might consist of 4 lines, each with four system at system generation time. 
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Three facilities are made available through the macro 
generation capabilities of any OS/360 or DOS/360 assem- 
bler language translator. During assembly of a problem 
program, macro instructions coded by the user are expanded 
into: 


e Linkages to the executable BTAM routines, 


e Tables defining the lines, terminals, and options to be 
used, 


e Buffer areas. 


Initial communication between a user problem program 
and BTAM is established upon execution of an OPEN macro 
in the problem program. This also establishes communica- 
tion between BTAM and 1/O supervisor. 


After an OPEN is executed, a message may be sent or 
received by the simple execution of a WRITE or READ 
macro instruction, causing a branch and a link transfer of 
control to the BTAM Read/Write routine. This routine 
first builds a channel program to perform the operation, 
then passes control to the I/O supervisor which starts exe- 
cuting the channel program just developed. At this point, 
control passes back to the problem program, and the chan- 
nel program is executed concurrently with the problem 
program. 


An important feature of BTAM is the ability to 
repeatedly restart channel programs in response to condi- 
tions occurring on the communications line. Thus, a single 
READ macro instruction can cause successive polling of a 
number of terminals without any intervening direction from 
the problem program, which is notified only when a message 
has been read. Similarly a single WRITE can signal a 
number of terminals to prepare to receive. 


Another feature of OS BTAM is dynamic buffering, by 
which BTAM can interrupt the problem program to secure 
additional input buffer areas as needed. 


BTAM Facilities 


BTAM is easy to use. The programmer need only define 
control blocks and terminal lists (for polling and addressing) 
before performing the following simple functions: 

e Open 


e Read/Write messages 


e REQBUF/RELBUF ~ to request and release buffers 





BTAM is not a complete TP system. The BTAM user must: 
e Comprehend its basic capabilities and limitations; 


e Have a reasonable understanding of terminal and TCU 
equipment; 


e Provide programs, initiate operations, test for excep- 
tional conditions, and make decisions on control flow 
and the disposition of data; 


e Provide routines for any necessary scheduling and alloca- 
tion functions. 


BTAM is an ideal tool for constructing TP programs. 
Since it is a general purpose interface for input/output with 
TP equipment, it can be used as a component in the devel- 
opment of more sophisticated TP systems. It can also be 
employed in supporting a few TP lines on a computer con- 
figuration with limited available memory space. 


Installations considering extensive augmentation of 
BTAM functions should carefully weigh this task against the 
alternative of using the more comprehensive QTAM program. 


QTAM 


QTAM includes all the facilities previously described for 
BTAM. In fact, QTAM branches to a variation of BTAM 
for dynamic generation of channel programs to send and 
receive messages. However, QTAM is much more than an 
extension of BTAM capabilities. It not only controls mes- 
sage transmission between remote terminals and the central 
computer but also controls message queuing on a direct 
access secondary storage device. QTAM is a control 
program in its own right, and it provides synchronous oper- 
ation for all programming based on completion of events, 
availability of resources, and processing priorities. 


Storage Requirements 


QTAM operates under both the Disk Operating System and 
the full Operating System. Although operating systems 
incorporating QTAM have a minimum storage size of 32K 
bytes for DOS and 64K bytes for OS , representative systems 
generally require 64K and 128K bytes respectively. The 
space taken by QTAM varies according to user-selected 
options, and there is no simple rule to provide a realistic 
storage estimate. However, the following approximations 
may be useful for obtaining a general awareness of QTAM 
storage requirements. 
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The subroutines for message control occupy about 
8K-12K bytes for primary storage. Many of the macro 
instructions generate in-line linkages to functional subrou- 
tines. If the same macro is used more than once, space is 
needed for the linkage, but only one copy of the subroutine 
is provided. A typical macro might generate 10—15 bytes of 
in-line linkage, while the subroutine might occupy 100 or 
so bytes. Space is also needed for control blocks, tables, 
polling/addressing lists, and channel programs and related 
areas. In addition, since QTAM performs message process- 
ing functions, as well as message control functions, storage 
is needed for these processing routines. 


The following example indicates the approximate storage 
needed by QTAM to process a typical large TP config- 
uration. Assume 15 lines each with 6 IBM 1050 terminals 
and another 15 lines each with 6 AT&T 83B3 stations or 
Western Union Plan 115A stations. Assume further that 
two 100-character buffers are allocated for each line and 
that message processing has three representative routines 
operating on three process queues held on one direct access 
device. The QTAM storage requirements for this system 
would be in the range of 25,000 - 35,000 bytes. 


Description 


The overall organization of QTAM is shown in Figure 11. 
As can be seen, data sent by terminals is collected in core 
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buffers and then moved to disk queues for later message 
processing. Results are then moved to another queue to 
await output, again via a core buffer, to a destination ter- 
minal. 


This message flow, shown in more detail in Figure 12, 
can be considered in the following seven steps: 


1. The input message, consisting of message header and 
text, is prepared at a remote terminal. The header 
portion normally contains codes denoting source and 
destination terminals as well as a message sequence 
number and priority information. When the source 
terminal is polled, the message is sent to the com- 
puter. 


2. The message enters the computer and is placed in 
user-defined, fixed-length buffers. As many buffers 
are allocated as are necessary to contain the message. 
QTAM affixes a header prefix containing information 
for control and queuing purposes. Each of the 
remaining buffers has a text prefix, also containing 
control and queuing information, that precedes the 
text data. As soon as each buffer is filled, QTAM 
performs such user-selected functions as code trans- 
lation, routing, time and date stamping, and sequence 
checking. 
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Figure 11. QTAM Organization 
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Figure 12. QTAM Message Flow 
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3. If the message requires additional processing, each 
segment is sent to a process queue (input queue), 
which may be either in main storage or on a direct 
access storage device. 


4. User-written routines can GET messages, segments, or 
records from this queue and process them. Following 
this, the user can PUT the message into an output 
(destination) queue. 


5. If no processing (steps 3 and 4 above) is required, the 
message may proceed directly to a destination queue. 


6. Message segments are retrieved from the output queue 
on a FIFO basis within priority groups. 


7. Message segments are stripped of header and text 
prefixes and sent to the destination terminal as one 
continuous message. 


Facilities 

Since QTAM employs many of the programming techniques 
described earlier (under Teleprocessing Programming Tech- 
niques), the remainder of this section, briefly describing 
some QTAM facilities, is organized around the same 
topics used earlier: allocation and scheduling, buffering, 
queuing, message control, and message processing. 


The initial allocation of the storage areas is static and is 
specified by the user, while allocation of individual seg- 
ments within these areas is done dynamically. Normally, 
messages move to a disk queue while awaiting processing, 
but there are programmer options available to expedite 
messages by bypassing the disk phase. 


QTAM scheduling is designed to optimize use of the com- 
munication lines. The scheduling is a function of resource 
allocation in contrast to the opposite approach of first allo- 
cating resources and then scheduling by events. 


Buffering is accomplished by dynamic assignment of stor- 
age segments. To conserve storage space, buffers are 
emptied as quickly as possible. The same buffer pool is used 
both for terminal input/output and for holding messages 
awaiting service by message processing programs. 


Queues are specified for both processing tasks and desti- 
nation terminals. Queues are organized to minimize the arm 
motion of the disk access mechanism and are managed by 
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means of queue control blocks residing in core memory and 
containing all information necessary to schedule and locate 
the associated queued items on the disk. 


An enumeration of other QTAM functions in addition to 
the allocation and scheduling, buffering, and queuing func- 
tions just described gives some idea of its message control 
capabilities: 


e Controls all message traffic between central computer 
and remote terminals; 


e Performs such message editing functions as code transla- 
tion and header analysis; 


e Routes messages to destination terminals or to processing 
routines; 


e Optionally logs all or certain messages; 


e Performs numerous error detection and correction proce- 
dures including intercepting, rerouting, or cancelling of 
messages in error 


The user-written message processing programs operate as 
one or more individual tasks and communicate with QTAM 
to initiate, activate, and terminate the QTAM message con- 
trol program. In addition, GET/PUT logic is used for pass- 
ing messages through the message queue, which is the main 
connection between a system message control task and a 
user message processing task. 


SUMMARY 


BTAM is a general purpose input/output interface; QTAM 
is a complete TP system in its own right. Without modi- 
fication, QTAM can perform some applications, message 
switching for example, in their entirety; in other cases, it 
provides most processing functions that are common to a 
variety of TP applications. Its design accommodates a 
majority of the system applications, equipment character- 
istics, and programming techniques introduced in_ this 
manual. 


More detailed information on BTAM and QTAM iscon- 
tained in the reference manuals listed in the bibliography. 





acknowledge . . . to respond to polling or addressing, or to 
receipt of a message. 

acknowledgment . .. the act of sending a response to 
polling or addressing, or to receipt of a message; also, the 
character or character sequence comprising the response. 
An acknowledgment to polling or addressing may indi- 
cate the status of the terminal that sends it; an acknowl- 
edgment to a message may indicate whether it was 
received without error. 

address (n.) .. . the coded representation of the destination 
of a message. 

address (v.) .. . to condition a terminal for receiving data. 

allocate . . . to assign a system resource to a specific func- 
tion. 

answering station .. . the station responding to a dialed call; 
opposite of originating station. 

audio (a.)... within the range of frequencies which can be 
heard by the human ear (usually in the range 15-20,000 
Hertz [cycles per second] ). 

Auto Answer . . . the facility of an answering station to 
automatically respond to a call. 

Auto Call... the facility of an originating station to auto- 
matically initiate a call. 


band ... the range of frequencies between two defined 
frequencies. 

bandwidth . . . the difference, expressed in Hertz (cycles 
per second), between the two limiting frequencies of a 
band. 

batch processing . . . processing of data after a number of 
similar input items have been accumulated and grouped 
together; contrast with in-line processing. 

bit... contraction of binary digit. 

bit rate .. . the speed at which bits travel over a communi- 
cation channel, usually expressed in bits per second. 


buffer . . . a storage device used to compensate for a differ- 
ence in the rate of flow of information, or the time of 
occurrence of events. 


call directing code (CDC) . . . a code used to address a ter- 
minal (a Western Union term). 

channel... a path for electrical data transmission between 
two or more stations; also called circuit (not synonymous 
with data channel in computer usage). 

channel, duplex ... a channel providing simultaneous 
transmission in both directions. 

channel, half-duplex . . . a channel capable of transmission 
in both directions, but only one direction at a time. 
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channel, simplex . . . a channel which permits transmission 
in one direction only. 
channel, voice-grade . . . a channel suitable for transmission 


of speech. 


character ... the actual or coded representation of a digit, 
letter, special symbol, or control function. 

character, check . . . a character used for validity checking 
purposes. 

character, control .. . a character used for control purposes. 

character, graphic . . . a character used for printing or display. 

checkpoint . . . a point in a computer program at which suf- 
ficient information can be stored to permit restart of 
processing from that point. 

circuit .. . a connection between two or more points; usu- 
ally, a physical, metallic path. 

coaxial cable . . . a cable consisting of two concentric con- 
ductors insulated from each other. 

code... a system of symbols and rules for their use in rep- 
resenting information; also, the coded representation of a 
character. 

code unit .. . the number of bits used to represent a trans- 
mission character. 

code level . . . the number of bits used to represent a data 
character. 

communication .. . the transfer of information from one 
point to another. 

communication common carrier . . . a company recognized 
by an appropriate regulatory agency as having a vested 
interest in furnishing communication services. 

contention (n.)... the condition on a multipoint communi- 
cation channel when two or more locations try to trans- 
mit at the same time. 

contention (a.) .. . relating to a communication system in 
which contention can occur. 

conversational . . .a mode of communication involving the 
alternate sending and receiving of data. 

cyclic checking . . .a method of error control employing a 
weighted sum of transmitted bits. 


data collection .. . the process of bringing data from one or 
more remote points to a central point. 

Data Phone ... a term used by AT&T to describe any of a 
family of data set devices. 

data set . . . a device containing the electrical circuitry nec- 
essary to connect data processing equipment to a com- 
munication channel; also, called subset, Data Phone, 
modulator/demodulator, modem. (Not to be confused 
with the IBM System/360 Operating System term.) 
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data transmission . . . the sending of data from one place to 
another or from one part of a system to another. 

demodulation . . . the process used to convert communi- 
cation signals to a form compatible with data processing 
equipment. 

dial exchange . . .a common carrier exchange in which all 
subscribers originate their calls by dialing. 

display unit . . . a terminal device that presents data visu- 
ally, usually by means of a cathode ray tube. 

dynamic allocation . . . the technique of assigning storage 
areas during processing; contrast with static allocation. 


EBCDIC ... abbreviation for extended binary coded 
decimal interchange code. 

end of address . . . control character(s) separating message 
address(es) from message text; often abbreviated EOA. 

end of message . . . control character(s) denoting the end 
of a message; often abbreviated EOM. 

end of transmission . . . control character(s) denoting the 
conclusion of data transmission; often abbreviated EOT. 
It is usually sent by an originating station to signify that 
it is finished with the communication line. 

exchange service . . . a service permiting interconnection of 
two customers’ telephones through the use of switching 
equipment. 


FIFO ... abbreviation for first-in, first-out queuing, in 
which items are removed from a queue in the same order 
as entered; contrast with LIFO. 

free form .. . formatting of data fields by embedded delim- 
iter characters rather than organizing of data in fixed- 
length fields. 


group addressing . . . a technique for addressing a group of 
terminals by use of a single address. 


hard copy .. . a machine-printed document, as opposed to 
visually displayed data. 

header . . . initial portion of a message containing any infor- 
mation, control codes, etc., that is not a part of the text. 
Usually includes information for routing the message to 
its destination(s). 


in-line processing . . . processing of input data in random 
order, without preliminary editing, sorting, or batching; 
contrast with batch processing. 

in-plant system . . . a system confined to one plant locality. 

interface .. . a shared common boundary between two 
systems or two devices; for example, a physical connec- 
tion Or a programming convention. 


LIFO .. . abbreviation for last-in, first-out queuing, in 
which the next item to be removed is the most recently 
entered item in the queue. Also called “‘stack”’ or “‘push- 
down;” contrast with FIFO. 
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LRC ... abbreviation for longitudinal redundancy checking 
method, in which parity is checked longitudinally along 
all the characters comprising a transmitted record. 


mark state . . . state of a communication line corresponding 
to an on, closed, or logical one condition; contrast with 
space State. 

message . . . a finite sequence of transmitted words and/or 
symbols. 

message routing . . . the function of selecting the route, or 
alternate route, by which a message will proceed to its 
destination. Sometimes used to mean “‘message 
switching.” 

message switching . . . the technique of receiving a message, 
storing it until the proper outgoing circuit is available, 
and then retransmitting it. Also called “store and 
forward switching.” 

modulation . . . process used to convert signals from data 
processing equipment to a form compatible with com- 
munication facilities. 

modem... contraction of modulator-demodulator (see 
data set). 

multiple address message . . . a message which is to be deliv- 
ered to more than one destination. 

multiplexing .. . the interleaved or simultaneous trans- 
mission of two or more messages on a single channel 
during a given time interval. 

multipoint line . . .a communication line interconnecting 
several stations. 

multiprogramming .. . the interleaved (that is, concurrent) 
execution of two or more programs by a single computer. 


narrow-band (a.) . . . denoting a communication channel 
capable of a transmission rate of up to 300 bits per 
second. 

network . . . a series of points interconnected by communi- 
cation channels. 

network, leased line or private wire . . . a network reserved 
for the exclusive use of one customer. 


off-line ... pertaining to devices not in direct communica- 
tion with a computer. 

on-line . . . pertaining to devices in direct communication 
with a computer. 

out-plant system . . . a system not confined to one plant or 
locality. 


parity check . . . a test to determine whether the number of 
ones (or zeros) in an array of binary digits is odd or 
even. 

point-to-point transmission . . . transmission of data between 
two points. 

polling . . . a flexible, systematic, centrally controlled method, 
for permitting stations on a multipoint circuit to transmit 
without contending for the line. 





priority indicators ... groups of characters in the header of 
a message, specifying the order of transmission of messages 
over a communication channel. 


queue ... a group of items awaiting processing by some 
facility. 


real-time processing . . . processing data rapidly enough to 
provide results useful in directly controlling a physical 
process or guiding a human user. 

record .“.. a group of related data items treated as a unit. 

response .. . equivalent to acknowledgment (which see). 

response time . . . the interval between completion of an 
input message and receipt of an output response. 

restart .. . to return to a previous point in a program and 
resume operation from that point; often associated with 
a checkpoint. 


shutdown . . . temporary termination of computer proc- 
essing to be resumed at some later time. 

space state . . . state of a communication line corresponding 
to an off, open, or logical zero condition; contrast with 
mark state. 

startup ... initiation of computer processing or resumption 
of it from a point of temporary termination. 

start-stop mode .. . a mode of data transmission in which 
each character is delimited by special control bits 
denoting the beginning and end of the sequence of data 
bits representing the character; contrast with synchronous 
mode. 

static allocation .. . the technique of assigning fixed storage 
areas prior to processing; contrast with dynamic alloca- 
tion. 

store and forward switching . . . see message switching. 

stunt box ...a device to control non-printing functions of 
a teletypewriter terminal. 

subset . . . a modulation/demodulation device designed to 
provide compatibility of signals between data processing 
equipment and communication facilities. Also called 
modem. 

synchronous mode... a mode of data transmission in 
which character synchronism is controlled by timing 
signals generated at the sending and receiving stations; 
contrast with start-stop mode. 


tariff... the published rate for a particular approved com- 
mercial service of a common carrier; also, a list of 
services provided and requirements for their use. 


telecommunication . . . communication by electromagnetic 
systems; often used interchangeably with communication. 

TCU ... abbreviation for transmission control unit. 

Teleprinter .. . trade name used by Western Union to refer 
specifically to telegraph page printers. 

Teletype . . . trademark of the Teletype Corporation. 





Teletypewriter .. . trade name used by AT&T to refer 
specifically to telegraph page printers. 

Teletypewriter Exchange Service (TWX) . . . a semi-automatic 
switching service provided by AT&T for interconnecting 
public teletypewriter subscribers. 

Telex ... an automatic switching service provided by 
Western Union for interconnecting teleprinter subscribers. 

Telpak ...a tariff offered by AT&T for leasing or broadband 
channels. 

terminal unit .. . equipment on a communication channel 
that may be used for either input or output, or both. 

text... that part of a message which contains the informa- 
tion to be conveyed; contrast with header. 

tie-line . . . a leased communication channel or circuit. 

time-share . . . to interleave the use of a device or system 
for two or more purposes. 

transmission . . . the electrical transfer of information from 
one location to another. 

transmission control unit .. . a unit to interface communi- 
cation lines with a computer. Sometimes abbreviated as 
TCU. 

turnaround time . . . the interval of time between submission 
of a job for computer processing and receipt of results; 
the time interval required to reverse the direction of trans- 
mission Over a communication line. 

TWX... abbreviation of Teletypewriter Exchange Service. 


unattended operation . . . use of a terminal unit without an 
attending operator. 

USASCII. . . United States of America Standard Code for 
Information Interchange. 


voice grade line .. . a channel suitable for transmission of 
speech. 

VRC... abbreviation for vertical redundancy checking method, 
in which parity is checked vertically across each character 
in a record. 


voice-band (a.) . . . denoting a communication channel 
capable of a transmission state exceeding 300 bits per 
second; a channel suitable for transmission of speech. 


WATS . .. abbreviation for AT&T’s Wide Area Telephone 
Service, providing a special line on which the subscriber 
may make unlimited calls to certain zones on a direct 
distance dialing basis for a flat monthly charge. 


wide-band (a.) . . . denoting a communication channel 
capable of a transmission rate greater than about 18,000 
bits per second. 


Word ... in telegraphy, a word consists of six code combi- 
nations. 
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